Loser du logiciel libre ; anatomie d’un projet : yahi
Avril 2025
licence anti gad elmaleh: fait ce que tu veux de ce livre excepté dire
que tu l’as écrit
Avril 2025
licence anti gad elmaleh: fait ce que tu veux de ce livre excepté dire
que tu l’as écrit
Aujourd’hui, avec ma femme (surtout ma femme), on a payé les factures, la situation est pas bonne. Ma fille court après la chienne qu’elle a adopté ce qui me met en rogne car on a pas le pognon pour ça, mais elle heureuse.
Belle maman, parle polonais, avec ma femme, et je peux pas me concentrer, et c’est le quotidien que j’ai quand elle est pas en vacance. Justement, elle vient de partir une semaine en vacance, j’ai pu faire un logiciel libre, ou plutôt terminer un la finitions d’un logiciel commencé il y a 12 ans : yahi.
J’ai pas eu le temps de terminer cette phrase que ma femme est venu me voir pour me demander où était l’alimentation du dernier gadget inutile qu’elle avait jeté et qu’évidemment j’avais récupéré.
Pendant que le bruit et les stimuli négatifs m’entourent, j’essaie de pas taper du pied comme j’aime faire ou me pencher d’avant en arrière écoutez du rock fort ou tout ces autres tics qui me calment, car c’est ni familialement ni socialement acceptable. Et pourtant, sans je peux pas coder.
Faire du logiciel libre quand on vit dans la vraie vie c’est pas facile.
Mais pourquoi on en fait ?
Comment ?
Qu’est-ce qui nous motive ?
Tout ça sachant que si on a trouvé un bon truc un gros va arriver avec ses gros sabots pour s’approprier le logiciel et se faire du pognon avec sur notre dos sachant que le procès pour plagiat tu peux toujours te le carrer dans le cul quand t’as pas une tune. Je sais ça m’est arrivé avec pypi-stat qui a permis à un glorieux inconnu d’en tirer la gloire et les revenus.
Ce livre, c’est à propos de tout ça.
Avant de parler du développeur parlons du cycle de vie d’un projet logiciel libre fait sous python.
Voilà un rapide aperçu :
On commence par une idée qui pourrait intéresser des gens. Il faut trouver un angle d’attaque originale soit en apportant une solution nouvelle à un problème ancien, soit dans mon cas en proposant une solution ancienne à un problème nouveau.
Parfois, soyons honnête, l’envie me prend d’être polémique et ce paquet est polémique (je reviendrais plus tard sur les motivations à faire ce paquet et sur l’idée).
On code dans son coin et normalement, étant dans des conditions parfaites « ça marche pour moi », c’est l’équivalent du savant fou qui travaille sur un coin de paillasse. C’est soyons honnête le niveau où les éditeurs professionnels s’arrêtent souvent, leur valeur ajoutée étant dans le fait qu’il est difficile pour les concurrents de déployer leur logiciel.
C’est là où les non initiés pensent que le travail est fini. Que nenni, il faut passer de la phase « ça marche chez moi», à «ça marche partout».
En python on a un mécanisme de paquet qui permet d’installer les paquets de manière uniforme avec leurs dépendances grace à la commande pip qui sert à installer des paquets
Qu’on utilise une procédure manuelle (peu recommandée) ou automatique (recommandée) il faut quand un bug apparaît avoir un bout de code qui permet de vérifier que le bug a disparu.
Ce bug doit être préférentiellement lié à une entrée de bug qui permet à un utilisateur simplement de savoir en lisant dans la doc la partie changelog si il a disparu. Et à cette résolution de bug on fait correspondre un numéro de version.
Selon les conventions, on fait correspondre des incréments de numéros mineurs aux bugfix, intermédiaires aux « bris d’API », quand le code n’est plus totalement pareil en comportement, et on garde le dernier numéro pour les changements d’API majeurs.
Une API c’est le nom qu’on donne à l’interface avec le programme et ses différentes options.
« Good Enough »© correspond à une blague du joueur du grenier sur la finition logicielle qui en français se traduit par suffisamment bon.
Quand le paquet est stable, et qu’on a une documentation suffisamment bonne pour expliquer clairement en peu de ligne ce que le code peut faire, et qu’on a résolu la plupart des bugs bloquants on est «good enough».
Pourquoi «good enough» et pas parfait ? Car sans utilisateurs vous ne verrez pas tout les bugs, et vous préférez commencer avec le maximum de bugs shootés d’une balle dans la nuque, à tout le moins pour pas être ridicule.
En général, c’est la phase où vous recherchez des béta testeurs pour valider que ça marche un peu mieux que dans votre visions des tests que vous avez, et souvent « la vraie vie » vous fait découvrir des bugs.
Ça consiste à prendre son bâton de pèlerin, faire la tournée des sites qui parlent de logiciels libres et user son peu d’estime de soi à s’exposer à différents trolls dont ceux du « c’est pas PEP8 », « t’as passé le W3C validator » et autres personnes qui jugent un logiciel sur la forme et pas sur le fond.
J’admets que c’est la phase que je déteste, et je reviendrais plus tard sur pourquoi on s’inflige cette souffrance.
La gloire c’est de la vanité, ça sert à rien, mais si son projet est reconnu dans la vie d’un loser, ça donne l’impression d’avoir achever quelque chose. Pas grand chose, mais quelque chose.
Si vous avez « bien évangélisé » où que vous êtes doué dans le domaine, vous souhaitez que votre paquet soit intégré à une distribution. Le taf de mainteneur de paquet de distribution est une charge supplémentaire consistant à gérer la relation entre la distribution (debian, BSD, windows, conda…) et celui qui FAIT le paquet. On peut faire les deux. Mais c’est compliqué.
Maintenant, un quidam peut faire pkg install yahi et profiter des fonctionnalités annoncées par l’idée que vous avez eu. C’est la fin du chemin. Le logiciel est fini.
Entre la Qualité standard entreprise (j’ai forcé le trait en disant que les entreprises livrent à la va comme je te pousse, mais pas trop) et la qualité logiciel libre il y a 10 fois d’efforts en terme de temps et de travail. Le logiciel est la partie émergée de l’iceberg.
Voilà maintenant que j’ai présenté le cycle de vie d’un logiciel libre, je vais pouvoir parler de l’humain, le loser du libre qui en fait et les défis (challenge en français de Paris) que ça représente.
Si la partie ingénierie, empaquetage du logiciel est un acte de calme et de silence reposant où l’on peut se focaliser sur bâtir quelque chose, la phase évangélisation est une putain de plaie dans le cul pour les introvertis.
Comprenez bien que contrairement à une entreprise souvent le logiciel libre est développé en mode «one man army» où pour dire en français t’as pas d’amis tu fais tout (ou presque) tout seul.
Pour ce projet, il serait faux de dire que je suis seul, mais il serait menteux de dire que j’ai pas 99% des commits sur mon dos. Et je suis heureux d’avoir un ami qui m’aide (tuck que je remercie ici).
C’est le moment où l’on est forcé de prendre une pause car on est plus maître de l’horloge.
C’est le moment parfait pour écrire un livre, et c’est depuis cette phase que j’écris ce livre, dans ce moment où le doute nous étreint face aux critiques et que l’on se demande pourquoi on fait tout ça ?
Avant de revenir à comment on le fait, dans la vraie vie et les différentes catégories de sites où l’on peut poster en fonction de l’épaisseur de sa couenne, il m’est avis qu’on ne peut pas comprendre cette partie sans comprendre les motivations personnelles, et l’auteur.
Donc, expérience stressante, je vais comme parler de moi à la 3é personne.
La vie de codeur en entreprise n’est pas rose en tout cas, celle que j’ai connu.
Dire que l’on fait de la merde est un pléonasme, l’entreprise ne semble pas avoir pour but de produire, mais de fournir des positions sociales qui reflètent plus les travers de la société.
Comme certains disent, le code est politique, il reflète dans son organisation, son développement et même son ingénierie une vision sociale, sociétale dirons certains de nos communautés.
J’abuse de terme que ne connais pas en parlant de névrose. Pour moi une névrose c’est quand la main gauche fait quelque chose que la main droite réprouve. Genre, t’es pour aider les miséreux mais tu tournes le dos au squidjie qui te demande une pièce.
Je fais parti de la première génération d’«amateur» de l’informatique, celle qui a grandi en tapant sans comprendre les listing papiers en basic d’hebdogiciel (un magazine disparu sur l’informatique).
Je vais vous gâcher la fin : taper sans comprendre sert à rien.
Mes deux véritables ouvertures à la programmation ont été car à l’époque j’avais les moyens ma calculatrice programmable (une HP48) et quelques années plus tard linux (slackware).
Et j’ai découvert quelque chose de merveilleux : LA DOCUMENTATION.
En 1993 quand on installait encore linux à coup de disquette car les CDROMs étaient pas si courant, on pouvait acheter pour pas cher des ouvrages en papier bible avec tous les HOWTO linux. Et ça, ça m’a vraiment aidé.
La qualité de documentation qui m’a permis de devenir autonome, auto-didacte je dirais, est ce que je préfère. De nos jours, pour cette raison, je préfère installer freeBSD sur mon serveur car les pages de manuels sont bien écrites et suffisantes.
La qualité « logiciel libre » est devenu le standard que je voulais atteindre au moins une fois dans ma vie. Sur ce chemin, j’ai fait de nombreux essais et pour l’instant n’ai connu que des échecs.
Vous me direz pourquoi persévérer : t’es pas doué, t’es pas doué, lâche l’affaire et arrête de perdre du temps et des points de santé mentale que tu pourrais consacrer à ta famille. Et je suis d’accord.
Néanmoins, j’arrive pas à me laisser compter « KO ». J’aimerais toujours faire du « beau code » et « en vivre ».
Suite à mon dernier taf où je me suis fait harceler (et menacer physiquement (quelle nouveauté)) je suis en dépression, et il paraît que pour sortir d’une dépression, il faut avoir « un projet ».
Donc, sans mentir, je mets mes tripes dans mon code et aussi de la critique technique, des processus et de l’ingénierie.
Comme par exemple, je peux pas saquer les scrums meetings et l’hypocrisie du développement agile. Coder sans est un vrai plaisir et violer le maximum de règle de l’agile (non je ne mettrais pas de lien vers cette daube dont on peut lui faire dire ce que l’on veut) est une volonté délibérée.
Pas de user-story, pas de planning, pas de rétro-planning, de toute façon, quand on est seul ça fait pas de bon sens.
La chose important dans « logiciel libre » n’est pas tant qu’il libère son utilisateur, qu’il libère celui qui code de normes étouffantes et inutiles. Pouvoir ne pas faire comme en entreprise et délivrer est une propagande par le code contre tout ce qui ne va pas en entreprise en ce qui me concerne.
C’est un moment cathartique pour moi pour oublier tout ce qui m’empêche de livrer avec la qualité qui me sied. Et c’est pour ça que je vise le graal du paquet de distribution, pour me prouver à moi même que je ne suis pas fou et que ma critique politique de l’entreprise donne bien un résultat pertinent et valide.
En logiciel libre, on conseille de toujours partir pour écrire un logiciel de partir d’un problème que l’on a et pour lequel on cherche une solution. De gratter là ou ça démange (scratch an itch en anglais).
Bon, là, le problème a disparu il y a 12 ans quand j’ai émigré au Canada et où j’ai tellement avancé mon salaire à mon employeur avec l’aide d’un franco que je suis tombé dans la misère.
Faîtes moi confiance, une fois que l’on tombe dans la misère c’est dur de simplement redevenir pauvre.
Je distingue le pauvre celui qui ne manque de rien mais ne peut se payer le superflu, du miséreux dont le manque de caillasse fait que sa santé se détériore, l’empêchant d’utiliser son seul capital, son corps pour devenir salarié.
Donc, quand j’étais pauvre je faisais de l’auto-hébergement, ce que je considérais être mon portfolio de sysadmin établissant ma crédibilité à être sysadmin.
Mon serveur était un centrino pas péchu délibérément ; mon crédo a toujours été de faire le max que l’on peut avec le moins possible.
Il était une fois, un jeune moi à la fac de Paris VI qui suivait après moults échecs les conseils de sa grand mère : ne cherche pas à être bon, fait juste le minimum pour passer. Grâce à ses conseils, mes notes se sont améliorées, mais il y eût dans mon histoire académique une exception ; le cours d’assembleur.
Durant ce cours, j’avais un voisin, fils d’ingénieur, qui un jour m’a expliqué que je ne pouvais pas savoir coder car je ne possédais qu’un ordinateur d’il y a 2 générations ; un 486DX2 66Mhz avec bus VLB et lui un pentium PCI 90Mhz SMP. Et que quelque part, j’étais juste une daube.
Ça m’a eût énervé.
Et j’ai décidé dans cette matière d’investir un peu d’énergie. C’est d’ailleurs comme ça que je l’ai poutré en terminant le premier notamment grâce aux TPs, en prenant le même TP que lui (manipulation de bras de robot) et en le ridiculisant avec un code largement plus simple qui marchait le jour de la livraison.
Je peux pas vous dire comment ça m’a fait du bien. Et depuis, je regarde avec circonspection les tenants du « c’est pas grave de pas savoir bien coder, la machine peut compenser ».
À l’époque pour le fun j’ai développé une librairie qui donne des propriétés d’algèbre linéaire aux dictionnaires python
Et en pratiquant la librairie, je m’étais rendu compte qu’elle était pratique pour agréger les statistiques en utilisant moins de code.
J’avais aussi la pratique des regexps nommées qui transforme le résultat d’une regexp en dictionnaire.
M’est alors venu l’idée simple il y a 12 ans de faire une librairie de regexp de journaux de serveurs, pour en agréger les statistiques et j’ai jeté sur un coin de table un serveur flask pour servir les vues par pays sur une carte, les histogrammes et les séries temporelles.
Et j’étais fier que ça tournait sur mon intel celeron sans mémoire cache.
Puis récemment, mon ami tuck m’a dit, j’aimerais faire du logiciel libre, t’as pas un projet sympa qu’on pourrait livrer ?
Vu que je suis psychotique d’après 3 de mes anciens patrons, j’ai peut être entendu des voix, mais peu importe : un truc me chagrinait sur ce projet : LE SERVEUR FLASK.
Donc, je m’ai dit livre un agrégateur de statistique de serveurs (serveur que je n’ai plus, trololol, ça aide pas à développer) en … défi … roulement de tambour … en une page HTML qui contienne tout.
Si une chose me casse les bonbons en code moderne, c’est les dépendances inutiles.
En tant que sysadmin d’entreprise j’en ai déployé des solutions énergivores et complexe basées sur de multiples couches (grafana, qui terminent dans le cloud pour faire des stats webs par agrégations.
Yahi est littéralement ma réponse personnelle à ce délire de couches complexes qui s’empile pour au final un rendu qui ne sert que la vanité. Un truc qui transforme les journaux web de base en une série de visualisation « good enough »© en UNE seule page web hébergeable sans avoir besoin d’invoquer npm, react, vue, grafana et tutti quanti.
J’avais envie de revenir à un truc de base, simple en tentant en plus en tant que développeur de ce que l’on appelle le « back » (la partie arrière d’un site web qui concerne l’authentification, l’autorisation, le rendu des bases de données, les interactions serveurs) de faire un coup de pied de la mule aux développeurs « front » (la partie visible qui attire le regard) en faisant le plus possible de code moi même sans cadriciels.
En conclusion, l’idée en faisant ce code n’était pas tant de délivrer un résultat que d’interroger les pratiques modernes de code en entreprise qui veulent que tout devienne chancre de dépendances, énergivores. Parce qu’il faut pas se leurrer, un framework, une infra cloud en plus, c’est du CO2 inutile qui est inutilement généré, et quelque part, vu que c’est inutile : ça m’énerve. Donc, j’ai mis beaucoup d’effort à tenté de faire le moins de code possible.
Ce code ne parle pas de statistiques de serveur de page web, mais de la frustration intrinsèque à faire des usines à gaz qui sont tout le contraire de pour moi ce que devrait être la programmation : être le moins dispendieux en ressources (librairies, CPU, mémoire) pour être le plus accessible à tous possible.
C’est un cri du cœur face à ma névrose d’entreprise, je fais le contraire de ce que l’on nous incite à faire pour me libérer de cette croyance que je trouve aliénante et débile.
Heureux qui comme Ulysse quitte Nausicaa non en la maudissant, mais en la bénissant – James Joyce
Il faut savoir dans la vie garder une attitude positive face à ses expérience pénibles dit James Joyce, et préférer les regrets aux remords.
En ceci, j’ai peut être oublié que fût un temps, ma vie fût faste, j’étais même invité à me bourrer la gueule gratis à la fête de l’Huma pour parler logiciel libre entre « happy few ».
Je faisais parti des gens qui était invité à parler du logiciel libre et participait à une magazine libre à plusieurs mains « libroscope » qui a aujourd’hui disparu faute de tune pour payer l’hébergement.
C’est un des trucs de notre époque, nos mémoires ne restent contrairement au papier que le temps et l’argent que l’on peut mettre dans le jukebox des OPEXs (coûts d’opérations/hébergement).
Tu tombes dans la misère et les 48€/ans d’hébergement + 48€ de noms de domaines ne sont plus une priorité. Libroscope a disparu du web, son aventure aussi. C’est même impressionnant pour moi qui avait écrit des articles sur le sujet que le numérique était une menace pour la mémoire d’en être témoin de première bourre.
Au moins, les livres, je les imprimes, je les relies mal et je les stocke.
Dans les choses que j’ai eu faites avec mes complices (r4f, tpi, antoine) il y a eu la direction de thèmes aux RMLL (Rencontres Mondiales du Logiciel Libres), lieux où RMS (Richard Maximus Stallman) himself m’a eu traité de démon pour avoir dit que je faisais du logiciel libre non par « convictions idéologiques » mais pour le fun.
Notre thème était « le libre au delà du logiciel ». Si vous cherchez mon nom il a été effacé sans citation après que j’ai eu déplaît à quelques obscures associations du libre. Il paraît que j’étais pour certains un « stalinien » pour d’autre « une petite bite ». Pour des gens qui respectent la propriété intellectuelle, j’eus aimé qu’ils respecta à minima le droit de paternité.
Mais, je ne maudirais pas ma déchéance de ce milieu. L’extraversion nécessaire à l’exercice n’étant pas quelque chose qui forcément m’aidait à montrer le meilleur de moi même.
Parlons des bons cotés.
Mis à part les confs où l’on était invité en Savoie, à Bourges, Metz et ailleurs (ce qui était chouette), il y avait aussi des rencontres sympa.
J’ai eu l’occasion de boire des verres avec framasoft et de rencontrer des devs du libre, comme ceux de Spip sur lequel tournait libroscope ou Aymeric Moizard (ANTISIP).
Aymeric m’a dit un truc qui m’a marqué, et m’a changé : le logiciel libre il y a ceux qui en parle, et ceux qui en font, et c’est pas les mêmes.
Je devais ma situation de « privilégié » à avoir fait parti des premiers codeurs à investir les boîtes du libres de l’époque et j’étais au centre de l’intelligentsia, là où l’influence se construisait.
Mais du point de vue développeur, même si j’avais quelques projets sous le coude pour télécharger des images de nudes sur NNTP ou d’aide à la drague sur meetic, disons que mon code était de qualité professionnel. Je n’avais pas encore franchi l’étape de devenir un « vrai dev libre ».
Une autre rencontre qui m’a marqué quand j’avais 10 ans était monsieur Souillot, qui nous a appris à faire du cyclotourisme. Il était officier de police judiciaire, mais soupirait que notre société ne nous permettait pas d’avoir plus d’une vie dans une vie.
De tout reprendre à zéro pour tenter de voir le chemin qui nous plairait.
Et consultant, vendeur de boniments était pas le truc qui me plaisait le plus. En plus j’aimais pas trop les gens que ça obligeait à fréquenter n’étant pas très versé en politique et diplomatie.
J’avais envie d’aller faire ce que je respectais : faire du logiciel libre et non plus en parler.
C’est comme ça que sur le tard, j’ai décidé d’arrêter les projets potaches, voire malaisants pour me mettre à coder sérieusement comme je pensais que ce serait bien de le faire. Un peu comme mon grand père tailleur de pierre qui n’était pas fier de son métier, mais de montrer des photos de ses « œuvres ». J’avais envie comme lui de montrer « mon art », une manière de faire différente « de la norme d’entreprise » qui me semblait plus inspirante.
Et, soyons honnête, malgré les galères, je ne le regrette pas.
Depuis 2012, date où j’ai commencé à me mettre sérieusement à faire des paquets python il y a de l’eau qui coulé sous les ponts.
Et l’on peut se demander pourquoi j’ai pris une semaine de ma vie pour faire un tunnel à finaliser un vieux projet.
J’avais des tas de vieux projets sur lesquels j’aurai pu investir du temps :
En fait, mon projet préféré c’est archery. L’utilisation de trait pour surcharger les opérateurs +, -, *, / pour les dict en python et en faire des vecteurs de fait.
Et il se trouve que yahi était une preuve de concept de l’idée.
Si j’avais mieux testé il y a 12 ans j’aurais vu qu’il manquait un fichier pour l’installer avec pip, trolololol.
Le « troll » dans yahi est que l’agrégation tient en UNE ligne qui utilise archery :
Quand j’additionne deux dictionnaires l’un à l’autre, évitant en python de vérifier que la clé éxiste, la créer et SI elle existe additionner pour chaque clés les résultats. Je suis fier d’archery, et yahi est un écrin autour d’une bête ligne de ce code.
Et ça c’est archery à l’œuvre. Les 300 lignes autour, c’est de la doc, du sucre, des « helpers » (aides) et de l’enrobage.
C’est la différence entre du code d’entreprise où finalement on valorise LA ligne de code, et le code libre où l’enrobage, la documentation, les tests importent.
Après 13 ans, j’ai vu le problème à dépendre de librairies externes ; les librairies javascript hors de celle de google pour la cartographie ne marchaient plus. Un peu comme libroscope avait disparu, mais dépendances avaient disparu aussi, et je me suis dit « crotte », t’avais même pas besoin de les mettre à jour, si seulement t’avais gardé une version figée de l’époque t’aurait pas eu ce problème.
Et puis il y avait flask aussi qui était à la mode à l’époque et dont heureusement je n’utilisais pas de module car la plupart d’entre eux n’ont pas été mis à jour, et je me suis dit, si seulement tu dépendais pas de flask tu prendrais encore moins de risques.
J’ai eu du flair pour une chose, le mode de format de journaux « Apache log combined » est devenu le standard de fait, Common Log Format laissant la partir agrégateur de démo (speed_shoot) toujours fonctionnel à ma grande surprise.
Mon ancien moi avait été sympa, me laissant un framework de test, un de doc et suffisamment de doc pour reprendre le code là où je l’avais laissé sans avoir à ni réinventer la roue, ni me replonger dans le code source.
À partir de là, j’avais mon approche dite « top down » (du haut vers le bas), la grosse image qui me permettait de conduire les petites modifications du bas vers le haut (« bottom up »). Et qui allait guider un projet que j’évaluais en temps entreprise à un mois homme et qui m’a pris pour l’instant une semaine homme en négligeant tout le reste.
Le gestionnaire de version de code, est le meilleur allié du codeur.
En l’occurrence, j’ai honte j’utilise github, et non un outil moins problématique comme sourcehut.
Mis à part que microsoft travaille pour l’immigration américaine qui a des relents fascisant ou pour la défense, j’ai vécu l’épisode traumatisant en logiciel libre de l’épisode sourceforge.
Loin dans le temps, une entreprise qui se voulait bienveillante offrit les premières forges intégrées de développement. L’ancêtre de gitlab et github.
La vie y était merveilleuse, et dans notre inconscience à l’époque nous miment nos projets comme un seul homme sur cette plateforme. Quelques grognons prévinrent (GNU/savannah) que ça allait nous péter à la yeule cette mono culture, et qu’on se trouverait bien con le jour où la forge changera de licence ou de business model. Surtout, que nos projets à héberger représentaient pour ceux qui avaient comme profession l’hébergement un montant substantiel en entretien des serveurs et achat de bande passante.
Nous ne les écoutâmes pas, et l’hiver venu fûrent forts dépourvus.
La morale de cette histoire, c’est que la monoculture des outils et plate-formes surtout est fort périlleuse et est comme une épée de Damoclès au dessus de nos têtes. Souvenons nous que les iraniens et russes sont bannis de github … ce qui est fort problématique.
En une semaine de temps, je n’ai pas vu la fenêtre d’effort disponible pour migrer. Par contre, je me suis fait un serveur de backup git où je double commite mes modifications, et aussi je partage préférentiellement le lien non vers github mais pypi qui est le lieu où l’on stocke nos modules pythons finis et qui sert de base à pip.
J’ai juste un doigt d’intégration hors git pur avec github : la file de ticket.
Quand je commit avec le message fix #numéro, le commit dans github pointe vers le ticket et le ticket est fermé.
C’est la fonctionnalité que j’utilise le plus.
À chaque fois que je code ou vois un problème qui n’est pas mon tunnel de concentration actuel, je m’ouvre un ticket avec juste assez pour que ma mémoire sache de quoi ils s’agissent. Et c’est ma méthode de bourrinage dans l’approche « bottom up » bourrin : écrire des tickets et les fermer jusqu’à disparition des tickets.
Ensuite, je peux lire ce que j’ai mis dans les tickets pour faire le journal de modifications (changelog) et liés aux étiquette de versions qui correspondent (à peu près lol) aux versions que je pousse sur pypi.
C’est une approche « rinse et repeat » (répète jusqu’à plus soif) qui a fait ses preuves.
Vous pouvez voir sur les tickets que j’ai pointé qu’ils sont volontairement concis même quand ils résultent dans des gros changements.
̈́## De l’utilité des PoC (preuves de concept)
Alors distinguons une preuve de concept (PoC) d’une preuve de concept.
Il y a la bonne PoC et la mauvaise PoC.
Il y a celle d’entreprise qui est une façade front pour un produit fini, mais en fait derrière il y a rien, c’est une PoC façade, et la PoC de codeur qui au contraire en terme de rendu est à chier mais illustre la mécanique derrière pour résoudre une tâche de conception.
Dans le cadre de yahi, à partir du moment où je me suis fixé arbitrairement pour le fun de servir tout ce qui était nécessaire en une page, il me fallait un routeur virtuel.
Évidemment, pour ça je me suis pas mis de tickets, ça aurait été trop facile pour démontrer ma cohérence.
Par contre j’ai bien commencé par faire une PoC pour le routage de niveau 1 puis une Poc pour le routage de niveau 2 à partir de là seulement une fois en confiance que j’avais shooté le chemin critique, j’ai fait un billet de blog pour (me l’) expliquer le principe du routage virtuel en javascript, pour le mettre dans un commit que j’ai mal documenté.
Pauvre moi.
Pour virer l’API google jsapi, j’ai aussi commencé par une PoC avant de faire le chantier.
L’erreur est humaine la perfection diabolique selon l’ancien proverbe.
Certes, je fais de multiples erreurs, je souffre de syndrome de gros doigts, dans ma précipitation j’étiquette mal des commit, mais à chaque incrément, même en local, je putain de test que les résultats sont conformes aux attentes avec un
pip install .. ; speed_shoot test/*log* > data.js ; yahi_all_in_one_maker data.js ; firefox aio.htmlEt je vérifie manuellement que les pages sont conformes à mes attentes.
Pourquoi, parce que pour les tests visuels à part selenium je sais pas faire. Et là encore, quand on est solo en temps limité, on investit son capital temps judicieusement ; hors de question de faire des tests des rendus visuels tant qu’à minima :
Deux conditions qui ne sont pas encore remplies.
La définition de terminé avant de se lancer dans l’évangélisation est importante.